Перейти к основному содержимому

7.07. Устаревшие подходы

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Инженеру

Устаревшие подходы​

В эволюции информационных технологий многие методы, протоколы и практики, ранее считавшиеся стандартными, оказались уязвимыми к современным атакам. Их применение сегодня — не просто технический анахронизм, а прямая угроза безопасности системы. Ниже перечислены и проанализированы категорически устаревшие или опасные подходы, которые не должны использоваться в новых проектах и подлежат замене в существующих.

1. Устаревшие криптографические хэш-функции​

MD5​

Алгоритм MD5, разработанный в 1992 году, был изначально ориентирован на контроль целостности, а не на безопасное хранение паролей. Однако долгое время он применялся для хэширования учётных данных.
Проблемы:

  • Коллизии могут быть найдены за считанные секунды на обычном оборудовании.
  • Полностью скомпрометирован: существуют готовые rainbow tables и сервисы обратного поиска.
  • Не обладает устойчивостью к атакам по времени и предвычислению.

Статус: запрещён для любых задач, связанных с безопасностью (RFC 6151).

SHA-1​

Хотя SHA-1 значительно надёжнее MD5, к 2020-м годам были продемонстрированы практические атаки нахождения коллизий (проект SHAttered, 2017).
Проблемы:

  • Сниженная стойкость к коллизиям делает его непригодным для цифровых подписей и сертификатов.
  • Уже не поддерживается ведущими браузерами и ОС как стандарт для TLS.

Статус: устарел, не рекомендуется даже для целостности; заменён на SHA-2 (SHA-256, SHA-384) и SHA-3.

Важно: ни MD5, ни SHA-1 никогда не предназначались для хранения паролей. Их использование для этой цели — грубейшая ошибка.

2. Небезопасные алгоритмы симметричного шифрования​

DES (Data Encryption Standard)​

Разработан в 1970-х, использует 56-битный ключ.
Проблемы:

  • Ключ слишком короткий: перебор возможен за часы на коммерческом оборудовании.
  • Уязвим к атакам на основе дифференциального и линейного криптоанализа.

Статус: объявлен небезопасным NIST в 1999 году.

3DES (Triple DES)​

Являлся временной заменой DES: применяет DES трижды с разными ключами.
Проблемы:

  • Эффективная длина ключа ниже заявленной из-за слабостей конструкции.
  • Медленный и неэффективный по сравнению с современными алгоритмами.
  • Уязвим к атаке «встреча посередине» (meet-in-the-middle).

Статус: запрещён для новых применений (NIST SP 800-131A, 2023); поддержка прекращена в TLS 1.3.

ECB (Electronic Codebook) — режим шифрования​

Часто ошибочно называют «EC4» (нет такого стандарта; вероятно, имеется в виду ECB).
Проблемы:

  • Одинаковые блоки открытого текста шифруются в одинаковые блоки шифротекста.
  • Нет диффузии: структура данных сохраняется (например, изображения остаются различимыми).
  • Не обеспечивает семантическую безопасность.

Статус: непригоден для шифрования данных с повторяющимися структурами. Допустим только для очень специфичных случаев (например, шифрование ключей по стандарту ANSI X9.52), но даже там предпочтительны другие режимы.

Современная альтернатива: AES (Advanced Encryption Standard) в режимах GCM (аутентифицированное шифрование) или CBC с корректной инициализацией (IV).

3. Хранение паролей без соли (salt)​

Хэширование паролей без соли — фатальная ошибка.
Проблемы:

  • Позволяет применять rainbow tables — предвычисленные таблицы хэшей для миллионов распространённых паролей.
  • Одинаковые пароли разных пользователей дают одинаковые хэши, что упрощает массовую компрометацию.
  • Не защищает от атак по словарю даже при использовании «сильного» алгоритма (например, SHA-256 без соли всё ещё уязвим).

Требование: каждый пароль должен хэшироваться с уникальной, криптографически случайной солью, длиной не менее 16 байт. Соль хранится в открытом виде рядом с хэшем.

4. Хранение секретов в открытом виде​

Plain text (открытый текст)​

Хранение паролей, ключей API, токенов или других секретов в виде простого текста — недопустимо.
Примеры уязвимостей:

  • Пароли в исходном коде (hardcoded credentials);
  • Логирование паролей или токенов;
  • Конфигурационные файлы без шифрования;
  • Передача учётных данных в GET-параметрах URL.

Последствия: немедленный компромет при утечке логов, репозиториев, дампов памяти.

Решение: использовать сейфы секретов (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), переменные окружения (с осторожностью), или зашифрованные конфиги с контролем доступа.

5. Самопальные криптографические схемы​

Разработка «собственного» алгоритма хэширования, шифрования или генерации ключей — один из самых опасных анти-паттернов.
Причины:

  • Криптография — область с чрезвычайно высоким порогом экспертизы.
  • Даже незначительная ошибка в конструкции делает систему полностью уязвимой.
  • Отсутствие peer review и долгосрочного анализа.

Принцип: никогда не изобретайте криптографию. Используйте только стандартизированные, широко проверенные алгоритмы и библиотеки (OpenSSL, libsodium, .NET Cryptography, Bouncy Castle).

6. Использование устаревших протоколов и механизмов​

  • HTTP Basic Auth без TLS — передача логина/пароля в Base64 (не шифрование!);
  • Digest Access Authentication — устаревший, уязвимый к атакам на перехват сессии;
  • TLS 1.0 / 1.1 — содержат критические уязвимости (POODLE, BEAST); запрещены PCI DSS с 2018 года;
  • SSLv3 и ниже — полностью скомпрометированы.